DRY up batched KVStore reads utility methods#876
DRY up batched KVStore reads utility methods#876tnull wants to merge 1 commit intolightningdevkit:mainfrom
KVStore reads utility methods#876Conversation
|
👋 Thanks for assigning @joostjager as a reviewer! |
|
🔔 1st Reminder Hey @joostjager! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @joostjager! This PR has been waiting for your review. |
|
LGTM |
|
This now needs a rebase, there's a merge conflict. |
|
🔔 3rd Reminder Hey @joostjager! This PR has been waiting for your review. |
joostjager
left a comment
There was a problem hiding this comment.
I am not sure a generic client-side read throttle is the right abstraction here.
I think the motivation is mainly VSS-specific? For local stores such as SQLite, this mostly limits task fan-out rather than real backend concurrency. Perhaps it should be implemented only in the VSS client. And perhaps longer term, a multi-key read would be helpful in the VSS protocol?
Hmm, I tend to agree, though pre-existing.
Well, yes, presumably postgres could also benefit from it, though the store probably should switch to connection pooling anyways?
Yeah, maybe for now I should just switch to wrap |
joostjager
left a comment
There was a problem hiding this comment.
Yeah, maybe for now I should just switch to wrap VssStore in BatchingStore in this PR? WDYT?
I think this is a good move, and later expand either towards protocol-level multi reads for vss, or perhaps generalize for other backends if the need arises.
|
Discussed offline, decided we're not going with the |
BatchingStoreKVStore reads utility methods
5b8cebf to
22866ab
Compare
joostjager
left a comment
There was a problem hiding this comment.
Looks good, uncontentious. Rebase needed.
| kv_store: &DynStore, logger: L, | ||
| ) -> Result<Vec<PaymentDetails>, std::io::Error> | ||
| /// Read all objects of type `T` from the given namespace, spawning reads in parallel. | ||
| pub(crate) async fn read_all_objects<T, L>( |
There was a problem hiding this comment.
I briefly had to think of making this an extension method, but don't think it is a great idea.
The parallel `JoinSet`-based batching loop was duplicated across `read_payments` and `read_pending_payments`. Extract it into a generic `read_all_objects<T: Readable>` helper that callers invoke directly with the relevant namespace constants. Per-type log messages are preserved via `std::any::type_name::<T>()`. Co-Authored-By: HAL 9000
22866ab to
7aa48fa
Compare
Rebased, sorry, forgot about that before. |
Uh oh!
There was an error while loading. Please reload this page.